A network architecture called “IP Multimedia Subsystem” (IMS) has been developed by the 3rd Generation Partnership Project (3GPP) as an open standard for handling multimedia services and sessions in the packet domain (for the detail of the IMS, please refer to http://www.3gpp.org/ftp/Specs/html-info/22173.htm). Various communication terminals and devices (hereinafter referred to as IMS terminals) that conform to the IMS standard are now known. A typical example of an IMS terminal is a mobile phone with IMS functionality. A personal computer (PC), a personal digital assistant (PDA), or the like can also serve as IMS terminals if they are equipped with IMS functionality. IMS terminals can provide multimedia services by, for example, receiving video streaming from a video-streaming server over an IMS network.
However, many communication terminals (hereinafter referred to as non-IMS terminals) still exist that are not IMS-enabled (i.e., that do not have IMS functionality). International Publication No. WO 2006/045706 discloses a multimedia gateway called a “Home IMS Gateway” (HIGA), which enables these non-IMS terminals to access the IMS network.
According to WO 2006/045706, the HIGA is located in a private network, to which at least one non-IMS terminal is connected. The HIGA includes a Session Initiation Protocol (SIP) Back-to-Back User Agent (B2BUA) for communications between non-IMS terminals and the IMS network. The HIGA also includes a SIP gateway (implemented according to 3GPP TS 24.229 and IETF RFC 3261). The SIP gateway allows inter-operation between various client terminal signaling protocols and the SIP used by the IMS. For example, the SIP gateway may provide translation between ISDN-based signaling protocols and the SIP. Accordingly, the non-IMS terminals may or may not have SIP functionality.
FIG. 1 schematically illustrates the structure of a HIGA known in the art. A HIGA 100 includes a B2BUA 101, a device database (DB) 102, and at least one IMS Subscriber Identity Module applications (ISIMs) 150. The HIGA 100 may also have a SIP gateway (not shown). As an example, in FIG. 1, ISIMs 150 comprises two ISIMs, ISIM 160 and ISIM 170. Each ISIM stores a single IMS Private Identity (IMPI) and at least one of possibly multiple IMS Public Identities (IMPUs). In FIG. 1, the ISIM 160 stores an IMPI 161 and IMPUs 162 and 163. The ISIM 170 stores an IMPI 171 and IMPUs 172 and 173.
Three SIP clients 110, 111, and 112 in a private network 180 are connected with the B2BUA 101. Moreover, the B2BUA 101 may communicate with an IMS network 181 over a Gm interface, which as such is known to a person skilled in the art through e.g., 3GPP TS23.228 V7.6.0. The IMS network 181 includes a Call Session Control Function (CSCF) 120 and an IMS application server (IMS AS) 121.
When a SIP client registers with a HIGA, the HIGA assigns one of the IMPUs to the SIP client so that an IMS network can identify the SIP client through the HIGA. A B2BUA in the HIGA is responsible for converting a local SIP identity into the IMPU and vice versa. Accordingly, if the SIP clients 110, 111, and 112 register with the HIGA 100, the HIGA stores a mapping table in the device DB 102 as shown in FIG. 2. The B2BUA 101 handles IMS signaling on behalf of the SIP clients 110, 111, and 112 such that all signaling concerning respective SIP clients is associated with the corresponding IMPI on the ISIM application. For example, if the SIP client 110 sends a SIP Register message to the HIGA 100, the B2BUA 101 translates the message into an IMS REGISTER message that contains both the IMPI 161 and the IMPU 162 corresponding to the SIP client 110. Thus, the HIGA 100 acts as an IMS terminal on behalf of the SIP clients 110, 111, and 112, thereby enabling the SIP clients 110, 111, and 112 to access the IMS network 181.
The conventional HIGA succeeded in mediating communication between SIP clients and an IMS network over a Gm interface. Thus, the SIP clients such as a SIP phone and an instant messenger that are not IMS-enabled could communicate with the IMS network by way of the HIGA.
However, functionality of the conventional HIGA is not sufficient when the IMS AS, with which the SIP clients communicate, acts as a Generic Bootstrapping Architecture (GBA) Network Application Function (NAF), which as such is known to a person skilled in the art through e.g., “Generic Authentication Architecture (GAA); Generic bootstrapping architecture,” 3GPP TS33.220 V7.3.0 (2006-03). One example of the IMS AS that also acts as a GBA NAF is an IP television (IPTV) AS. In this case, an IPTV client as a SIP client needs to access the IPTV AS not only over the Gm interface, but also over a Ua interface, which as such is known to a person skilled in the art through e.g., 3GPP TS24.109 V7.5.0. The Ua interface provides a secure authenticated channel, which is usually achieved using a Transport Layer Security (TLS) connection (sometimes with HTTP Digest authentication), between the IPTV client and the IPTV AS. The IPTV client can securely communicate with the IPTV AS over this TLS connection using an application protocol such as HTTP or RTSP.
FIG. 3 illustrates a situation where an IPTV client cannot communicate with an IPTV AS by way of the conventional HIGA. In FIG. 3, the same reference characters as in FIG. 1 designate the same or similar components as in FIG. 1, thus a description thereof will be omitted.
An IPTV client 300 includes SIP functionality 301 and an IPTV application 302. While the IPTV client 300 can make “indirect” access to an IPTV AS 310 that acts as a GBA NAF over a Gm interface via the B2BUA 101 of the HIGA 100, it cannot make access to the IPTV AS 310 over a Ua interface. In other words, while the SIP functionality 301 can communicate with the IPTV AS 310 via the HIGA 100, the IPTV application 302 cannot communicate with the IPTV AS 310 via the HIGA 100. This is because the IPTV client 300 does not have an ISIM application and thus cannot derive a NAF-specific key termed Ks_(ext/int)_NAF required to secure the Ua interface.